Multi-Protocol Label Switching (MPLS) is a mechanism in telecommunication networks which directs and carries data packets from a node to other nodes. Each data packet comprises a label stack, on which forwarding decisions are made without the need to consult the remaining part of the packet.
Based on the existing MPLS forwarding plane, the Multi-Protocol Label Switching Transport Plane (MPLS-TP) aims to provide a framework to fulfill transport network requirements. One key area is to have a well-defined Operations, Administration and Maintenance (OAM) function set. This OAM function set is under standardization in the Internet Engineering Task Force (IETF). The OAM framework and requirements define several functions (Continuity Check (CC), Connectivity Verification (CV), Management Signals, etc.) that should be supported by the developed OAM solution.
The operation of OAM for MPLS-TP is that the necessary OAM attributes (identifiers, timers, counters, etc.) are encoded in so called OAM frames that are multiplexed into the data flow. In this way fate sharing of the OAM frames and data flow is ensured, that is, the OAM frames and data flow experience the same process in being forwarded from one node to another. The OAM frames are generated and received by Maintenance EndPoints (MEPs) that reside at the endpoints of a connection.
Currently, the MPLS-TP architecture consists of three layers: Pseudowire (PW), Label-Switched Path (LSP) Tunnel (connection) and Section (data link) layers. The MPLS-TP OAM is supposed to support all three layers.
Currently, several competing solutions of encoding the OAM parameters are proposed. However, these solutions are based on the same method of multiplexing the OAM frames into the data flows. The method defines an associated channel to carry the OAM frames and other control/management frames. In the case of PWs, these channels are identified and de-multiplexed using only the Generic Associated Channel Header (G-ACH). In the case of LSP tunnels and sections, an additional label is defined to indicate the associated channels. This label is referred to as the Generic Association Channel Label (GAL). The egress side (i.e. the destination side) detects and de-multiplexes the OAM frames based on these labels.
However, these solutions relying on transmitting OAM frames within the G-ACH have the following problem in MPLS and MPLS-TP: in the case of LSP Tunnel and Section layers, the standard MPLS data forwarding mechanism does not provide sufficient method to address the MEPs from the data plane using identifiers being used for data plane forwarding as well.
The standard MPLS forwarding behaviour at a particular node is as follows. Based on the first label in the stack (the tunnel label) the node looks up a Next Hop Label Forwarding Entry (NHLFE). This entry instructs the node what to do with the label stack (pop the first label, change the value of the first label, push a new label on the top of the stack etc.) and where to forward the packet (next-hop node).
If the node is an egress node that terminates a connection, the NHLFE is encoded to instruct the node to remove, i.e. pop, the tunnel label from the stack and to perform a lookup on the remaining packet. If any further labels exist on the stack, a second independent lookup for the next label on the stack is performed. This second label can be a GAL, for example, meaning that the packet should be passed to the control function of the local node, and the GAL removed from the frame. Then, the control function of that node can process the frame and send the OAM packet to the proper MEP.
FIG. 1 shows a MPLS packet structure that may be used in the forwarding mechanism described above. A label stack comprises, for example, an outermost label which is a LSP tunnel label. This may either take the form of a label which explicitly identifies an egress node, or the form of a Time-To-Live (TTL) label which determines the egress node based on the number of hops. An associated channel header contains information which is processed by a G-ACH de-multiplexing process, while the G-ACH message payload contains the payload of the packet, for example an OEM payload to be sent to a MEP.
It will therefore be appreciated that the MPLS data plane does not allow a particular MEP to be addressed using data plane attributes (for example labels in the data plane). Instead, a MEP may only be addressed by de-multiplexing the OAM payload and using identifiers (i.e. routing information) within the OAM payload to address the appropriate MEP.
After de-multiplexing to the corresponding MEP, the correct connectivity should be verified using identifiers contained in the OAM payload. Although these identifiers are unique at either the node or the network level, the connection over which the packet was received cannot be identified, i.e. the incoming connection cannot be identified if multiple parallel connections exist between the ingress and the egress node. Furthermore, as described above neither the tunnel label (first label) nor the incoming interface are available after the OAM payload has been de-multiplexed. This means that it is not possible to verify the correct connectivity, i.e. not possible to perform a full Connectivity Verification (CV) operation.
A known solution proposed for MPLS-TP OAM connectivity verification is a linktrace-based method. However, this solution involves complex processing, not only at the endpoints of a connection but also at all intermediate nodes that forward a connection, because the method was originally designed for a different function. This has the disadvantage of consuming an undesirable amount of processing resources. The linktrace-based method also has the disadvantage of not being easily scalable.